Dialog control for dialog systems

ABSTRACT

A method and a system for developing a dialog control (DS) for a dialog system is described, which on the one hand has the task of controlling the dialog with the user and on the other hand monitors the speech user interface (SP) and the application (AP) of the dialog system. First of all a graphic dialog description (GB) is produced, which during the development process is displayed by a display device of the development system. Subsequently, the graphic dialog description (GB) is converted into a technical dialog description (TB) which comprises classes of an object-oriented translator language and translates these into a binary format, which ultimately represents the dialog control (DS) that can be executed by the dialog system.

The invention relates to a method and a system for producing a dialogcontrol for a dialog system, as well as a dialog system with a dialogcontrol of this type.

Dialog controls for speech-controlled user guidance of a dialog systemhave a broad commercial application field for speech portals of allkinds, e.g. in the case of speech-controlled information and serviceprovision systems such as telephone banking and the home dialog systems.Speech-dialog systems of this type have a speech input interface, viawhich the speech utterances of a user are recorded and evaluated, andalso as a rule a device for speech generation and speech output. As acentral control component, the dialog systems have a dialog control.This dialog control implements all valid speech dialogs in the form ofpredetermined, mutually conditional, reciprocal sub-dialogs between thesystem and the user, as well as the system-side responses that can bederived from that. The network of valid dialogs and their conditionaldependencies can become relatively extensive in the case of dialogsystems with correspondingly complex specification.

In principle, such a dialog control can be realized in the form ofhardware, for example as a ROM chip. Such hardware solutions aresuperior to a software solution in terms of execution speed, but offerno possibilities for adaptation to changed conditions. It is thereforesensible to realize the dialog control as software, and to make itavailable as such to the dialog system for execution.

In the development and production of speech-controlled dialog systems,the general problem arises that where the dialog system that is to becontrolled is of corresponding complexity, on the one hand it isdifficult for the dialog developer to gain an overview of the dialogcontrol. On the other hand, with each alteration to the specification ofthe dialog system, the so-called dialog description, a correspondingadaptation of the dialog control or the dialog description must takeplace, the fast and accurate feasibility of which is in turn restrictedby the complexity of the dialog description. Depending on the type orapplication of the dialog system, such alterations, e.g. as a result ofchanges in the ranges of goods and services on offer from an automaticsales system or their prices, may need to be carried out veryfrequently.

Typically, a dialog control with a specific development system isproduced by a dialog developer and subsequently loaded into the dialogsystem, where it is executed by its run-time system. If an alteration tothe dialog description is necessary, the dialog control must be readinto the development system, updated accordingly there, and subsequentlyloaded into the run-time environment of the dialog system again. Thesedays, mostly proprietary description and specification languages areused, these being mostly programming languages with a range ofinstructions specially tailored to the task. These languages have thedisadvantage that the dialog developer has to learn them especially forthe purpose of specifying the dialog control. Likewise, a client of themanufacturer of a dialog system or an external service provider can makean adaptation or change to the dialog description only after extensivetraining. That makes such systems extremely inflexible, and unusable forsome application areas. Furthermore, the dialog descriptions that are tobe produced or altered are often so complex that the development processor maintenance process can take up a considerable amount of time in thegiven framework of the proprietary language.

Such specification languages for dialog controls are mostly scriptlanguages which are executed on the dialog system by an interpreter.This has the principal disadvantage that due to the interpretation, theexecution speed of such dialog controls in the run-time environment ofthe dialog system is limited. Likewise, the development times ofscript-language programs that reach a certain level of complexity arelonger due to their being more difficult to structure. It may even benecessary, due to current technological developments, to expand therange of instructions or powerfulness of the specification language.This leads to the further disadvantage that both the interpreter of thedevelopment system and the interpreter of the dialog system must beadapted to the new range of instructions.

In principle it is also possible to realize the drafting of a dialogcontrol with the means of graphic or visual programming. However,considerable difficulties can arise here in mastering the complexity ofan extensive dialog description, since graphic tools as a rule provideonly proprietary methods with a specially tailored and thereforerestricted range of command structures and monitoring structures. Thegraphically developed dialogs developed in this way can then be madeavailable to the dialog system in the form of a script-language programas dialog control. However, graphic development systems that can berealized in this way do not have the necessary power to develop dialogsof any desired complexity.

It is therefore an object of the present invention to enable simple,flexible, fast and economical new production and adaptation of a dialogcontrol for a dialog system.

This object is achieved for one thing by a method for producing a dialogcontrol for a dialog system, in which an application developer first ofall produces a graphic dialog description by selecting and combiningsuitable graphically-represented dialog components. Here, the graphicdialog description is visualized by a display device. The dialogcomponents can for example typically represent frequently-occurring andre-usable standard sub-dialogs, such as greeting and closing dialogs,identification dialogs or information inquiries. Likewise, structuralcomponents of a dialog, such as for example the states that a dialogcontrol can assume, or state transitions, can be representedgraphically. The dialog developer can take these from an archive (e.g.from a dialog database or dialog library), and on the basis of thevisualization of the graphic dialog description, via well-definedinterfaces, can link them appropriately to the components that havealready been selected. According to the invention, this graphic dialogdescription is subsequently automatically converted into a technicaldialog description, which represents the created dialog in the form ofprogram codes of an object-oriented translator language. Since suchuniversal programming languages (e.g. Java, C++ or C#) are generallymore powerful in terms of calculation than graphic descriptionlanguages, the functionality of the graphic dialog description can bemapped in every case, through the conversion, onto an equivalenttechnical dialog description. After the developer has produced thedialog on the technical levels completely to his wishes, the technicaldialog description is then translated into machine code using a suitablecompiler, forming the dialog control, and can be installed on the dialogsystem for its immediate use. Compared with the usual use of a dialogcontrol that has been produced in an interpreter language or scriptlanguage, this has the advantage that the dialog control is available inmachine code, and in this respect works fast and reliably on the dialogsystem, whereas script programs must be interpreted through slowerinterpreters.

A significant advantage to using a universal rather than a proprietaryprogramming language lies in the possibility of being able to realizeany conceivable dialog. This yields the further advantage that suchdialog controls can be expanded at any time without expenditure, and canbe adapted to any technical or market-economy development.

The technical dialog description comprises classes of theobject-oriented programming language that has been used, which on theone hand can be derivations from basic classes and thus inherit certaincharacteristics of these basic classes, and on the other hand caninclude sub-classes for sub-dialogs, dialog states or dialogtransitions. In this way, class hierarchies can arise which as a wholerepresent the technical dialog description and ultimately specify thedialog control completely.

Dialog components or dialog modules that are written in any desiredobject-oriented programming language have the advantage that due to thedata encapsulation caused by the structure of the language, and theprecise definition of interfaces, they are in principle re-usable, andcan therefore be used again efficiently for subsequent new developmentsof dialog controls.

The dialog developer who has developed a dialog on the graphic level,through graphic selection and combination, can preferably execute andrefine the dialog more precisely on the technical level throughprogramming. Thus for example standard utterances of the dialog systemon the technical description levels can be adapted to a concrete dialogsituation, or the inquiry options open to a user that are specified in a(graphic) sub-dialog can be expanded by the addition of others.

The new writing of dialog classes on the technical description level canbe favorable for especially experienced dialog developers if they canprogram the dialog faster than they can develop it graphically.Likewise, the technical programming approach to development ispreferable if for example a dialog class of a particular level ofabstraction is required, which inherits characteristics and methods fromone or more classes, and a similar class is not available in a databasefor dialog classes. It can also be the case that certain dialogsituations cannot be realized, or can be realized only with difficulty,by a graphic description language that does not have full calculationcapability. In such cases, the dialog developer has the option offurther developing the technical dialog description with a programminglanguage that does have full calculation capability, and writing newobject-oriented classes that realize the concrete sub-dialog, in orderto incorporate these into the technical dialog description.

In any case, it is a particular advantage of the invention that thedevelopment of a dialog control can proceed in a particularly flexibleand problem-oriented manner, both on a graphic and on an equivalentprogramming-language level.

A further advantage of this distributed dialog development lies in thefact that the dialogs of speech-controlled dialog systems—these dialogsbeing present only in acoustic form in later operation, and these dialogsystems these days being capable of reaching a considerable degree ofcomplexity—are visualized on a graphic description level. The dialogdeveloper can thus obtain a better overview of them, and design thembetter. The intermediate step of conversion into a technical dialogdescription enables the dialog developer to adapt the graphic design ofthe dialog control precisely to the requirements set by the dialogsystem, or to the wishes of a client.

Here, the use of a conventional programming language such as Java or anobject-oriented C-derivative instead of a proprietary dialog descriptionlanguage is particularly advantageous, since thus not only the producerof the dialog system but also for example the client's maintenancepersonnel or specialized service providers can develop the dialogcontrol, and adapt it if necessary. All that is required here isinstruction in the programming interface (API) of the system. Inprinciple, any object-oriented programming language can be chosen here.

In order to ensure consistency between the graphic and the technicaldialog description, in one embodiment of the invention it is possible tointegrate a textual alteration of the technical dialog description intothe graphic dialog description again. The possible difference inpowerfulness of the graphic and technical description languages poses noproblem in the updating of the graphic dialog description, since throughthe strict syntax of an object-oriented programming language and itshierarchical structure due to inheritance and abstraction mechanisms,each dialog class can be graphically symbolized with its dependenciesand interfaces.

In a particularly advantageous embodiment of the invention, theconversion of the graphic dialog description into a technical one, aswell as the updating of the graphic dialog description by thealterations of a technical dialog description, takes place in anautomated manner, and in a manner that is transparent for the developer,in the background through the development environment. Through this, aquasi-parallel development by the dialog developer on both descriptionlevels simultaneously is even possible.

In the case of this embodiment, moreover, it is ensured that in the caseof user-controlled conversion of a graphic dialog description into atechnical dialog description, the consistency of the two descriptions isnot endangered by simple overwriting of the possibly altered classes orcomponents of the technical dialog description, but the surpluses of thetechnical dialog description compared with the graphic dialogdescription are preserved during conversion, and in turn are updated inthe graphic dialog description.

The classes/components for producing technical dialog descriptions canbe stored in full or in part, i.e. also individually, in a dialogdatabase or library. In the case of one embodiment, such technicaldescriptions of dialogs or sub-dialogs that are stored in a dialogdatabase can advantageously be read in from the dialog developmentenvironment and used as a starting point for the technical and—afterupdating—graphic new development of a dialog control. This enables there-usability of program fragments, and thus a high speed and efficiencyof development.

The technical dialog descriptions that are stored in full or in part ina database can comprise class hierarchies and class libraries thatrepresent particular important characteristics of dialogs in severallevels of abstraction. These class hierarchies too can, after being readinto the development environment in the form of technical dialogdescriptions, be represented as graphic dialog descriptions, in that therelations between the classes and the inherited methods andcharacteristics are visualized by suitable graphic symbols. From a classhierarchy that has been visualized in this way, a dialog developer canselect the classes that are sufficiently specified for his requirementsby selecting the corresponding symbol, and combine them appropriatelywith other dialog components. The precise specification of theindividual sub-dialogs and of the interfaces between them can forexample take place after a conversion of the selected and combinedcomponents into a technical dialog description by programming out theindividual classes. In this way, an advantageous distributed dialogdevelopment is realized, in which the structure of a dialog control isrealized on the clear graphic description levels, and the detailed worktakes place on the technical description level through programming.

In the case of an advantageous embodiment of the method according to theinvention, all technical components/classes of a technical dialogdescription are represented by symbols or as block lines or circle linesin the graphic dialog description. The graphic dialog description canthen be represented as a complete state/transition diagram of the dialogthat is to be realized through the dialog control. This has theadvantage that the state/transition diagrams that are frequently usedfor drafting dialogs can be converted directly into a graphic and thusultimately also a technical dialog description, if all classes orcomponents already exist.

In the case of this embodiment of the invention, the characteristics andmethods of a class can, advantageously, be made identifiable in thegraphic dialog description as elements of the class through symbols.Each symbol can bear a label which bears additional information, such ase.g. input and output parameters or interfaces, or which possibly evenstates the complete program code of the method or of the class. Likewisethe transitions between the individual dialog states are representedgraphically, wherein each transition can be assigned a label with thecorresponding statements and dialog steps of the system or of the user,which lead to the corresponding transition or which results in it. Witha graphic dialog description that is represented in this way, the dialogdeveloper can develop the linguistic, i.e. essentially acoustic, dialoggraphically and specify it more precisely, through simple mouseoperations such as e.g. dragging, moving, copying, inserting or cutting.In a particularly advantageous embodiment, by double-clicking on asymbol the dialog developer can open a text window in which he can maketextual alterations to the corresponding components, or can programthese. Through this kind of integration of graphic and textualdevelopment, convenient dialog development is made possible.

For such development of a dialog control for a dialog system, adevelopment system according to the invention is required, whichcomprises at least a graphic dialog editor with which the graphic dialogdescription can be visualized and edited. This development environmentfor dialog systems also contains a converter which converts the graphicdialog description into a technical dialog description which consists ofclasses of an object-oriented programming language. This source code isthen translated, by means of a translator (compiler) of the developmentsystem according to the invention, into binary description format, whichultimately represents the dialog control that can be executed on adialog system.

For the reverse conversion of a technical description into an equivalentgraphic dialog description, the development system preferably comprisesan updater.

For adapting the technical dialog description which represents thesource code of a dialog control, the development system preferablycomprises a text editor for textual editing of the source code.

In a particularly advantageous embodiment of the invention, besides atext editor there is also a complete programming environment withintegrated debugger, compiler and class browser for selectingobject-oriented dialog classes.

An advantage of this development environment lies in the fact thatcomplex and multi-layered acoustic dialogs can be drafted by a dialogdeveloper on the graphic level by means of adequate tools for editingand visualization through visual programming, whilst he can realize thedetails in the technical dialog description through object-orientedprogramming by means of a complete programming environment.

As an advantageous embodiment of the invention, the development systemthat has been described is integrated into the run-time environment ofthe dialog system, so that the dialog description can advantageously beproduced on that hardware platform on which it is taken into operationas the dialog control.

In the case of a dialog system that is controlled by a dialog controlthat has been developed with the development system described here, itis particularly advantageous that a translated dialog control can beintegrated into the system during operation. Through this, the dialogcontrol can be updated without the need for the system to be taken outof operation in order to install the updated dialog control. This is anadvantage particularly for systems which, due to constant specialoffers, for example, need to be updated particularly frequently.

The invention will be elucidated with reference to the enclosed drawingsand to example embodiments described hereinafter. In the drawings:

FIG. 1 shows a schematic representation of a dialog system,

FIG. 2 shows a flow chart of development, according to the invention, ofa dialog control,

FIG. 3 a shows a graphic representation of a dialog of a dialog system,

FIG. 3 b shows a graphic representation of a sub-dialog of a dialogsystem,

FIG. 4 shows an example of a technical dialog control,

FIG. 5 shows two sub-dialogs of the technical dialog control shown inFIG. 4.

A design example of a dialog system with a dialog control DS accordingto the invention, which works together with an application AP, a speechgeneration unit SG and a speech input interface SP, is shown in FIG. 1.The dialog control DS controls the dialog system in accordance with thestates, transitions and dialogs implemented by it.

An incoming speech utterance S is first of all converted into a digitalaudio speech signal AS by a signal recording unit SA of the speech inputinterface SP, and passed on to a speech recognition unit SE. The processof speech comprehension, i.e. the identification of an utterance knownto the speech recognition unit SE, is initiated by the dialog control DSthrough a start signal ST.

As a rule, the speech recognition unit SE integrated into the speechinput interface SP comprises a syntax analysis unit and a semanticsynthesis unit (neither shown here), which check the validity of thedigitized speech utterance AS according to a user grammar GR that isstipulated by the dialog control, and convert it into a recognitionresult ER which, as a response to the utterance of the user, comprisesprogramming language or machine code instructions. The recognitionresult ER is on the one hand sent to the dialog control DS, in order toallow this to regain control of the dialog procedure, and on the otherhand it is sent to the application AP, in order to be executed directlyby it. Alternatively, the recognition result ER can be sent by thespeech recognition unit SE only to the dialog control DS, in order to bepassed on by this to the application AP.

The dialog control DS is thus the central switching point of the dialogsystem, since it specifies the dialogs that are to be accepted as validby the speech recognition unit SE, and thereby indirectly controls theapplication AP. Furthermore, the dialog control DS also controls thespeech generation unit SG, which in accordance with the dialogimplemented in the dialog control DS, initiates generation of speechutterances by the system to the user.

As a rule, both the speech recognition unit SE of the speech inputinterface SP, the application AP and the dialog control DS are writtenin the same object-oriented translator language, or at least in alanguage that can be executed on the same platform.

FIG. 2 shows the schematic sequence of the development of a dialogcontrol. It also shows all the important components of a dialogdevelopment environment according to the invention. This includes agraphic dialog editor GE which represents a display and editing device,with which a dialog developer can visualize and draft a dialog. Forthis, various basic components are available to him, such as e.g.dialogs, states and transition, which are realized technically as basicclasses of a class hierarchy, and which he can select as graphic symbolsin the graphic dialog editor GE and can combine appropriately with othercomponents via well-defined interfaces.

The result of this first development cycle is a graphic dialogdescription GB, which initially exists only virtually, in the form of aninternal representation of the editor. The graphic dialog description GBis converted into a technical dialog description TB by means of aconverter UM, in that the individual (graphic) components of the graphicdialog description GB are converted into class instances of anobject-oriented programming language. These class instances representthe graphic components in programming language form (cf. FIGS. 4 and 5),for example as instances of basic classes for dialogs, states andtransitions, or in other words derived classes with inheritedcharacteristics for particular sub-dialogs.

The technical dialog description TB created by the converter UM can beedited by the dialog developer by means of a text editor TE, which canbe a portion of a perfected programming environment for the programminglanguage created by the converter UM. Through the possibility of editingthe technical dialog description TB, the dialog developer can programout the dialog control DS that is to be developed, i.e. supplement it bydetails which he either was not able to realize when drafting thegraphic dialog description GB or which are easier for him to realize onthe technical programming level.

Alterations which the dialog developer makes to the technical dialogdescription TB by means of the technical dialog editor TE can bere-integrated by an updater AK into the graphic dialog description, sothat the two levels of abstraction of a dialog development remainconsistent with one another. In the course of this, newly programmedclasses/components or methods of the technical dialog description TB arevisualized in the graphic dialog description GB by means ofcorresponding symbols, and these are linked according to the relationsof the newly programmed component with other symbols of the graphicdialog description GB.

In a particularly advantageous embodiment of the invention, the updatingAK is carried out such that through a renewed conversion UM of theupdated graphic dialog description GB, a technical dialog description TBis created which (after translation by a suitable compiler) showsidentical run-time behavior to that of the original technical dialogdescription TB that was altered by the dialog developer.

In a dialog database DB, sub-dialogs and standardized dialog elementsare stored in the form of program codes, which can be read into thetextual dialog editor TE as a technical dialog description TB, andaltered by the dialog developer, as the basis for a dialog that is to benewly developed, or as an expansion/alteration of an existing dialog.Likewise, existing dialogs and dialog components can be stored in thedatabase DB for later use. Since an object-oriented programming languageis used for the technical dialog description TB, the dialog database DBcan contain class hierarchies from which the dialog developer can selecta class of the abstraction level that is appropriate for his purposes,for programming out. Starting from these class hierarchies andlibraries, the development of a new dialog can take place on both thetechnical and the graphic description levels TB, GB, through derivationor inheritance and abstraction.

A finished technical dialog description TB is translated by a compilerUB into the machine code dialog control DS, which is finally integratedinto the dialog system shown in FIG. 1.

The (deterministic) behavior of the dialog control DS can be formallydescribed by means of a state/transition diagram that fully describesall the states of the system and the events that lead to a change ofstate (the transitions). FIG. 3 shows, by way of an example, thestate/transition diagram of a simple dialog HD which is realized by thedialog control DS. The dialog HD can assume a state S1, has a sub-dialogSD that is not specified in any further detail, in which in turn atleast one further state is specified, and also has four transitions T1,T2, and T3/T4, which are respectively initiated by a dialog step. Thetransition T1 maps the state S1 on itself, whilst the other transitionsT2 and T3/T4 describe a change of state between the state S1 and one ofthe states specified in the sub-dialog SD.

The state S1 is the initial state or starting state of the dialogsystem, which it assumes again at the end of each dialog with the user.In this state, the system generates a start phrase which prompts theuser to make an utterance: “What can I do for you?”. The two speechutterances “What time is it?” for initiating the transition T1 and “Whatis the weather forecast?” for initiating the transition T2 are now opento the user. In the first case, the system responds with the correcttime and then completes the corresponding transition T1, in that itreturns to the starting state S1, in order to give the startingutterance again. In the latter case, the system changes via thetransition T2 and the input interface IN into the sub-dialog SD. Fromthe sub-dialog SD, a transition T3/T4 leads via the output interface OUTback into the starting state S1, wherein the question posed intransition T2 is answered.

FIG. 3 b shows the corresponding state/transition diagram of thesub-dialog SD. It shows a state S2 which is linked via an inputinterface IN and an output interface OUT with the higher-order maindialog HD shown in FIG. 3 a. The sub-dialog SD has a state S2 which isreached via the transitions T2 from a state of the main dialog HD, andtwo transitions T3 and T4 which both undertake a change of state to astate specified in the main dialog HD.

After the dialog step “What is the weather forecast?” of the transitionT2, for more precise specification of the user request, the sub-dialogSD responds with the counter-question “For tomorrow or for next week?”and changes into the new state S2. In state S2, the user can only answerthe counter-question of the dialog control DS with the dialog steps “Fortomorrow” or “For next week”. In state S2, he no longer has the optionof asking the time; to do this, one would first have to leave thesub-dialog SD and the state S1 would have to be resumed. Onclarification from the user, the dialog control DS answersdifferentially with the weather forecast “for tomorrow” or “for nextweek”, and by means of the corresponding transition T3 or T4 it branchesvia the output interface OUT back into the main dialog HD, and then backinto the starting state S1.

The diagrams in FIGS. 3 a and 3 b represent an example of a graphicdialog description GB. The dialog developer design dialogs HDgraphically through specification of the states S1, S2, transitions T1,T2, T3, T4 and sub-dialogs SD. Here, the dialog steps can be associatedwith the corresponding transitions T1, T2, T3, T4 throughdouble-clicking and inputting of the text. In the conversion UM of thegraphic dialog description GB into a technical dialog description, thecomponents of the dialog HD (states, transitions and sub-dialogs) areconverted into a programming language version in the form of classes ofan object-oriented programming language. Such a conversion UM of thegraphic dialog description from the FIGS. 3 a and 3 b is shown in FIGS.4 and 5.

For elucidation, the following example technical dialog description TBis written in the object-oriented programming language C#. Fundamentallyhowever any other object-oriented programming language is suitable forthe definition of a technical dialog description TB. FIG. 4 shows themain dialog HD as a class “ExampleDialogue” which is derived from thebasic dialog class “Dialogue” that is stipulated by the system and whichinherits the characteristics of the class “Dialogue”. “ExampleDialogue”defines two states “state1” and “state2”, two transitions “WeatherTrans”and “timeTrans” and a sub-dialog “Weather”. Whereas the states “state1”and “state2” and the transition “WeatherTrans” are instances of thebasic classes “State” and “Transition” for states and transitions,“timeTrans” and “Weather” form instances of two classes likewiseimplemented by the dialog developer, which in turn are derived fromother basic classes and are specified in FIG. 5.

When instantiated by the calling up of four constructors, theInitializeO method of the class “ExampleDialogue” produces the objects“state1”, “WeatherTrans”, “timeTrans” and “Weather”. The object “state1”represents that starting state S1 which is associated with the dialogstep which the dialog system initially communicates to the user. Theobject “WeatherTrans” represents a transition T2 which changes from thestate “state1” S1 into a state of the sub-dialog SD “Weather”, and in sodoing outputs the given phrase. The object “timeTrans” maps the state“state1” S1 onto itself, and the object “Weather” represents asub-dialog SD, into which it is possible to branch from the state “state1” S1.

For complete specification of the dialog HD, what is now missing is aspecification of the classes “TimeTransition” and “WeatherDialogue”which are not yet known on this level, whose instances represent theobjects “timeTrans” and “Weather”. These are shown in FIG. 5.

The class “TimeTransition” is derived from the class “Transition”, ofwhich the object “WeatherTrans” of the main dialog HD already representsan instance. The class realizes only the answer to the question, whichwas already given as a parameter to the object “timeTrans” on itsinstantiation in the class “ExampleDialogue” of the main dialog HD.

The class “WeatherDialogue” is derived from the class “sub-dialogue”,which in turn contains a state “state” S2 and two transitions“TomorrowTrans” T3 and “WeekTrans” T4. This class represents thetechnical program conversion UM of the sub-dialog SD shown in FIG. 3 b.It responds to the question about the weather forecast (cf. parametersof its instantiation in “ExampleDialogue”) in accordance with thestate/transition diagram in the state “state” S2 with acounter-question, and then responds in a differentiated manner with thetransition “tomorrowTrans” T3 or “WeekTrans”. By ending the sub-dialogwith “Exit”, it then passes control back to the higher-order object ofthe class “ExampleDialogue”, which has instantiated the object “Weather”of the class “WeatherDialogue”.

The technical dialog description TB—comprising the three classes,described above, for realizing the main and sub-dialogs HD, SD—isfinally translated into machine code by the compiler UB (cf. FIG. 2),and thereby forms the dialog control DS. For the run-time of the dialogcontrol DS in a dialog system, a higher-order object of the class“ExampleDialogue” is instantiated by calling up the correspondingconstructor, which through its instantiation in turn of further objectsrealizes the complete dialog.

To conclude, it is once again pointed out that the concrete dialogsystem represented by the Figures and the description, and thedevelopment system, are merely design examples, which the person skilledin the art can vary to a large extent without departing from the scopeof the invention. In particular the program fragments, which in thedesign examples shown here are written in the object-orientedprogramming language C#, can be written in any other object-orientedprogramming language. It is furthermore clear that the dialog designexamples shown here are very simple, short examples, which were selectedin order to elucidate the invention as simply as possible. In realitythe dialogs are naturally considerably more complex. For the sake ofcompleteness, it is also pointed out that the use of the indefinitearticle “a” or “an” does not exclude the possibility that the featuresin question can also be present several times, and that the use of theterm “comprise” does not exclude the existence of further elements orsteps.

1. A method for producing a dialog control (DS) for a dialog system witha speech user interface (SP) and an application (AP), wherein die dialogcontrol (DS) works together with the speech input interface (SP) and theapplication (AP), with the following steps: production of a graphicdialog description (GB) comprising graphic dialog components, whichduring the production of the graphic dialog description (GB) aredisplayed by means of a display device, conversion of the graphic dialogcomponents of the graphic dialog description (GB) into technical dialogcomponents of a technical dialog description (TB) in the form of classesof an object-oriented translator language and translation of thetechnical dialog description (TB), whilst forming the dialog control(DS), into binary data that can be used directly by the dialog system.2. A method as claimed in claim 1, characterized in that the technicaldialog description (TB) can be textually altered, wherein if necessarythe graphic dialog description (GB) is at least partially supplementedby the textual alterations of the technical dialog description (TB), andthe supplemented graphic dialog description (GB) is displayed, and inthe conversion of a graphic dialog description (GB) into a technicaldialog description (TB) the textual alterations of the technical dialogdescription (TB) are taken into account.
 3. A method as claimed in claim1, characterized in that an existing technical dialog description (TB)is at least partly converted into a graphic dialog description (GB) asthe basis for producing a new graphic dialog description (GB).
 4. Amethod as claimed in claim 1, characterized in that givenobject-oriented classes of dialog description class hierarchies and/ordialog description class libraries are at least partially represented asgraphic dialog components, that the graphic dialog description (GB) isproduced through graphic selection, combination and/or alteration ofgraphic dialog components, and that the graphic dialog description (GB)is converted through derivation of the specified classes represented bythe graphic dialog components into technical dialog components of atechnical dialog description (TB) in the form of derived classes.
 5. Amethod as claimed in claim 1, characterized in that specified sub-dialogdescriptions are at least partially represented graphically as graphicdialog components, selected and integrated into a graphic dialogdescription (GB).
 6. A method as claimed in claim 1, characterized inthat in the case of the graphic dialog description (GB), all graphicdialog components are represented by symbols and the production of thegraphic dialog description (GB) takes place through the selection,copying and linking of the symbols and alteration of the technicaldialog components represented by the symbols.
 7. A system for producinga dialog control (DS) for a dialog system with a speech input interface(SP) and an application (AP), wherein the dialog control (DS) workstogether with the speech input interface (SP) and the application (AP),comprising a graphic dialog editor (GE) for visualizing and altering thegraphic dialog components of a graphic dialog description (GB), aconverter (UM) for converting the graphic dialog components intotechnical dialog components of a technical dialog description (TB) inthe form of classes of an object-oriented translator language, and atranslator (UB) for translating the technical dialog description, whilstforming the dialog control (DS), into binary data that can be useddirectly by the dialog system.
 8. A system as claimed in claim 7,characterized by a textual dialog editor (TE) for altering the technicaldialog description (TB) and an updater (AK) for at least partialsupplementation of the graphic dialog description (GB) by the textualalterations of the technical dialog description (TB).
 9. A system asclaimed in claim 7, characterized in that it is operational in the samerun-time environment as the dialog control (DS).
 10. A dialog systemwith a dialog control (DS), a speech user interface (SP) and anapplication (AP), wherein the dialog control (DS) works together withthe speech input interface (SP) and the application (AP), and the dialogcontrol (DS) has been produced with a method as claimed in claim
 1. 11.A dialog system as claimed in claim 10, characterized in that duringoperation, a new dialog control (DS) can be integrated and deployed.